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Description 
Technical Field 

[0001] This invention relates to data communications, 5 
and more particularly, to providing a Unicast endpoint 
client on a Unicast network with the ability to access a 
Multicast session on an Multicast network. 

Background of the Invention 10 

[0002] In conventional packet, frame or cell based 
systems there are typically two modes of communica- 
tion: point-to-point (also known as Unicast) and point- 
to-multipoint (also known as Multicast). Multicast ad- 15 
dresses typically differ from Unicast addresses in that 
they refer to an intermediate abstraction known as a 
group. All senders address their transmitted information 
to this group and all receivers are "tuned" to "listen" to 
that address to receive the information transmitted to 20 
that group by the senders. The senders of information 
are thus effectively de-coupled from the set of receivers. 
Senders do not need to know who the receivers are they 
simply transmit packets addressed to the group. Simi- 
larly, receivers do not need to know who the senders are 25 
- they simply send a request to the network (routers) to 
join a specific group of interest. 

[0003] Multimedia distribution and conferencing/col- 
laboration systems are advantageously and efficiently 
supported by Multicast communication methods. As will 30 
be used herein, a specific Multicast communication is 
referred to as a session. In the prior art, it is not possible 
for Unicast endpoints to access Multicast sessions, due 
to the differences in addressing modes and receiving 
modes. This disadvantageously limits the ability of a us- 35 
er at a Unicast endpoint client to participate in sessions 
in which they have interest and in which they could be 
an active participant. 

[0004] Djahandari, K. and Sterne, D.E., "An MBone 
proxy for an application gateway firewall, Proc. 1997 40 
IEEE Symposium on Security and Privacy May 1997, 
pp. 72-81 , describes an enhanced-security system pro- 
viding a firewall/proxy arrangement intermediate an In- 
ternet multicast router and network hosts having identi- 
fied Unicast IP addresses. Provision is made in the fire- 45 
wall/proxy to limit access by the hosts to MBone Multi- 
casts by using a number of security provisions, and to 
convert Multicast addresses to the Unicast addresses 
of approved hosts. 

[0005] Holfelder, W, "Interactive remote recording 50 
and playback of multicast videoconferences," Proc. 4 th 
International Workshop on Interactive Distributed Multi- 
media Systems and Telecommunications Services, 
(IDMS '97), 1 0 September 1 997, pp. 450-463 describes 
a remote recording and playback system for use over a 55 
Multicast network such as MBone. A Multicast client in- 
cludes a graphical user interface for interacting with a 
network server handling MBone Multicast sessions. 



Summary of the Invention 

[0006] In accordance with the present invention, Uni- 
cast endpoint clients are enabled to access Multicast 
sessions. Furthermore, in accordance with the present 
inventions, Unicast endpoint clients are enabled to re- 
quest network-based recording systems perform re- 
cordings of the Multicast session on behalf of clients. 
Even furthermore, in addition to LAN attached end- 
points, analog dial-up (e.g., 28.8 kbps) as well as ISDN 
Unicast endpoints are enabled to access appropriately 
bandwidth-reduced versions of nominally high band- 
width sessions. 

[0007] Inter-connectivity between a Unicast client 
connected to a Unicast network and one or more Multi- 
cast clients connected to a Multicast network is effected 
through a Multicast-Unicast Server (MUS), in accord- 
ance with the present invention. Such a server obtains 
information about sessions on the Multicast network and 
makes such information available to the Unicast client 
on the Unicast network upon request by the client. Upon 
being presented with a list describing the subject matter 
of each session, the user at the Unicast client selects 
the session to which he or she wants to join, which caus- 
es the Multicast-Unicast server to join the appropriate 
session on behalf of the requesting clientfor each media 
type for which the joining client wants to be a participant. 
The server then sets a bi-directional Unicast User Dat- 
agram Protocol (UDP) stream between itself and the cli- 
ent. All packets then received by the server from the Uni- 
cast client are address-translated to the appropriate 
Multicast session address. In addition, all packets re- 
ceived by the server on the Multicast session address 
are address-translated and sent to the Unicast client. 
The Unicast client is then able to participate in the Mul- 
ticast session as both a sender and a receiver of packets 
to and from other Unicast and Multicast clients which 
are active during the session. Further, such a Unicast 
client, if authenticated to do so, is capable of creating a 
new session, and of recording a session in the network 
for later retrieval and playback. Furthermore, transcod- 
ing and rate adapting gateways are deployed within the 
Multicast network that map existing sessions into low 
bandwidth versions. If the Unicast client is a dial-up user 
connected to the Unicast network over analog or ISDN 
facilities, these rate-controlled sessions can then be ac- 
cessed by the dial-up users. 

[0008] According to aspects of the present invention 
there is provided a method as specified in claims 1-22 
and a Multicast-Unicast server as specified in claims 
23-28. 

Brief Description of the Drawings 
[0009] 

FIG. 1 is a block diagram showing Unicast clients 
connected on a Unicast Internet Protocol (IP) net- 
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work accessing an IP Multicast network through 

Multicast-Unicast Servers (MUS's); 

FIG 2 is a block diagram of a MUS; 

FIG. 3 shows the software components of a client 

terminal that enable the client to access a Multicast 

session; 

FIG. 4 is a flowchart detailing the steps associated 
with a Unicast client joining a Multicast session on 
the Multicast network; 

FIG. 5 is a flowchart detailing the steps of a Unicast 
client creating a Multicast session; 
FIG. 6 is a flowchart detailing the steps of a Unicast 
client recording a Multicast session; and 
FIGS. 7 A and 7B together detail the steps of a Uni- 
cast client rate-adapting/transcoding a Multicast 
session. 

Detailed Description 

[0010] With reference to FIG. 1 , an IP Multicast net- 
work 1 01 is shown including, as way of illustration, three 
interconnected Multicast Routers (MR) 102-1, 102-2, 
and 102-3. A well known currently in place IP Multicast 
network is the so-called MBONE (Multicast Backbone), 
which is a public shared IP Multicast network spanning 
many countries and covering thousands of IP sub-net- 
works. In addition to the MBONE, numerous private In- 
tranets also use Multicast IP for intra-corporate commu- 
nications. A plurality of multimedia client terminals are 
connected to IP Multicast network 1 01 , for example the 
MBONE. For way of illustration only, in FIG. 1 two client 
terminals 1 03 and 1 04 are shown connected to network 
101 through respective Local Area Networks (LANs) 
105 and 106, respectively. Each LAN is connected 
through a customer premises router (not shown) over, 
for example, a T1 line, Frame Relay (FR), ATM, or an 
X.25 connection. In accordance with Multicast commu- 
nication, a sender of information of a particular media 
type transmits packets of information to a particular ad- 
dress, which are then automatically distributed to each 
of the members of a group that have requested to re- 
ceive from that address. Advantageously, the network 
performs the replication functions necessary so that 
each receiver client of the group can receive the packets 
transmitted to the address by a sender or senders. 
[0011] In accordance with the present invention, Uni- 
cast client terminals connected to a Unicast IP network 
is capable of joining in and participating with a Multicast 
session on an IP Multicast network. FIG. 1 shows two 
Unicast IP networks 1 07 and 1 08. Illustrative Unicast cli- 
ent terminals 1 1 0 and 1 1 1 are connected to network 1 07 
through conventional Unicast Routers (URs) 112 and 
1 1 3, respectively. Unicast client terminal 1 1 5 is connect- 
ed to UR 1 1 6 within network 1 08. U R 1 1 6 in turn is shown 
connected to another UR, UR 11 7 for example, which in 
turn is connected to UR 1 1 8. Networks 1 07 and 1 08 are 
shown as being interconnected through UR 112 and 
118, thus enabling Unicast IP communication between 



a client terminal connected to Unicast IP network 
107and a client terminal connected to Unicast IP net- 
work 108. The Unicast client terminals 110, 111 and 115, 
for example, can be connected to networks 107 or 108 

5 over a Plain Old Telephone Service (POTS) dial-up con- 
nection, an ISDN connection or an Asynchronous Digital 
Subscriber Loop (ADSL) connection, each to a Local 
Exchange Carrier (LEC) (not shown) and from there to 
an Internet Service Provider (ISP) (not shown), which in 

10 turn is connected to the Unicast IP network through a 
Unicast Router. Alternatively, a client terminal can be 
connected to an ISP through a cable modem over cable 
facilities through a cable TV provider. Even further, the 
Unicast client terminal could be connected to a LAN and 

15 to a customer premises router to a UR over, for example, 
a Wide Area Network (WAN), T1 facilities, Frame Relay, 
ATM, or X.25. In accordance with this invention, Unicast 
client terminals 110, 111, 115, for example, on Unicast 
IP networks 107 and 108, can participate in a Multicast 

20 |p session on IP Multicast network 101. Specifically, 
such functionality is enabled through Multicast-Unicast 
Servers (MUS's), such as MUS 120 in network 107 and 
MUS 121 in network 108, which each interconnect their 
respective Unicast IP networks 107 and 1 08, with the IP 

25 Multicast Network 1 01 . 

[0012] The Multicast-Unicast Servers 120 and 121 
function as gateways that enable those Unicast-con- 
nected clients on their respective Unicast IP networks 
to access IP Multicast network 101. Specifically, each 

30 MUS through interaction with client software on the Uni- 
cast client on the Unicast IP network enables such client 
to join a group on the IP Multicast network by providing 
information relating to what sessions are in progress or 
scheduled on network 1 01 . The MUS then receives and 

35 sends data on those groups within a session selected 
by client on behalf of the client. Thus, the MUS functions 
to convert the address of the Multicast IP packets of a 
requested-for group to the Unicast IP endpoint address 
of the requesting client. Furthermore, the MUS functions 

40 to transmit packets it receives from the Unicast endpoint 
client to a list of any other Unicast endpoint receivers 
for the requested-for Multicast group on the same Uni- 
cast IP network or an interconnected Unicast IP network 
(1 07 or 1 08), as well as to the Multicast group address 

45 itself on the IP Multicast network 1 01 to enable the Mul- 
ticast endpoints, 103 and 104, for example, connected 
on that network to receive packets originating from the 
Unicast client. 

[0013] FIGS. 2 and 3 are block diagrams of an MUS 
50 201 and a client terminal 301, respectively, showing 
their functions that enable them to operate in accord- 
ance with the present invention. In FIG. 2 a Session De- 
scription Protocol (SDP) listener process 202 coupled 
to the IP Multicast network 101 listens for session an- 
55 nouncements transmitted on Multicast network 101. 
Such directory announcements are repeatedly sent 
over the IP Multicast network 101. These "advertised" 
sessions are received by the SDP/SAP advertised proc- 
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ess 203 and stored in a sessions database 204. Other 
sessions that are not announced and thus not received 
by the SDP listener process 202, are entered by a sys- 
tem administrator through a static sessions process 205 
and also stored in sessions database 204. An example 
of the latter might be a weather channel that is always 
present on a predetermined socket and is not repeatedly 
announced over the IP Multicast network 1 01 . 
[001 4] An HTTP server 206 can read the sessions da- 
tabase 204 so that when a client connects to the server, 
the client is able to receive a listing of those Multicast 
sessions presently on the IP Multicast network 101. 
When the client connects to the server 206, the server 
executes a CGI (Common Gateway Interface) scripts 
207 within the HTTP server 206 on behalf of the client 
to present the information pertaining to the sessions to 
the client. Such information is presented back to the cli- 
ent 301 (FIG. 3) through its web browser program 302 
(in FIG. 3). The client initiates a request to join a session 
by selecting a URL on an HTML web page presented to 
it by HTTP server 206. A message is thus sent from the 
client 301 by web browser 302, which when received by 
server HTTP 206 causes it to invoke certain actions. 
Specifically, HTTP server 206 sends a response back 
to the client comprising a control message containing 
information indicating what tool needs to be used in or- 
der to join the selected session. Such tools are well 
known in the art and may include, for example, the Vis- 
ual Audio Tool (VAT), the Visual Conference Tool (VIC), 
or the Internet Protocol Television Tool (IPTV). Further- 
more, the message indicates where the tools should be 
connected, i.e., specifically, to which socket on the MUS 
the tool should be connected. On the client side, the cli- 
ent 301 then launches from launch program 303 the 
specified tool from tool program 304 to the indicated 
sockets on the MUS 201 . CGI scripts program 207 then 
initiates the translation/packet-forwarding server 208 
within MUS 201 to join the requested Multicast group or 
groups (one group per selected media type) associated 
with the selected session. CGI scripts 207 that initiated 
such join action to take place then adds that client's Uni- 
cast address to a list of receivers for the requested Mul- 
ticast group or groups. Server 208 then forwards Multi- 
cast packets received from the client to the list of receiv- 
ers for each joined group and translates the Multicast 
address of packets received from the joined group to the 
Unicast address of the joining client. 
[0015] The steps associated with a client joining a 
session are detailed with reference to the flowchart in 
FIG. 4. At step 401 , the SDP listener process accumu- 
lates I P Multicast network 1 01 directory announcements 
into database 204. The database is filtered and convert- 
ed into a standard HTML page, where each URL points 
to information pertaining to each Multicast session in the 
filtered database. At step 402, the HTTP server 206 lis- 
tens for requests for Multicast sessions/URLs on the 
HTML page which contains a list of URLs describing the 
sessions. At step 403, a request is received from a client 



for a copy of the page containing the Multicast sessions. 
At step 404, the HTTP server 206 sends a message 
back to the client requesting the user enter a login id 
and a password for authentication purposes. If the user 

5 is successfully authenticated at step 405, at step 406, 
server 206 returns a page to the client containing a list 
of sessions. When, at step 407, the user of the client 
browses the page and requests a session indicated by 
a URL, at step 408, server 206 returns a page containing 

10 details of the session and buttons enabling the client to 
request the session to start, as well as other functions 
to be described later herein. At step 409, the client starts 
a selected session (or specific media in the session) by 
"pressing" a button on the HTML page. The server 206 

15 then launches a control script 207. At step 41 0, the con- 
trol script 207 sends a response to the client containing 
information about which multimedia tool to launch, and 
what UDP sockets (the Unicast IP address on the MUS 
and associated ports) to listen to and to send information 

20 to corresponding to the requested group. It can be as- 
sumed that at least one socket is used. A second socket 
may be used to send control/status information from 
each member of the Multicast group. At step 411 , the 
same control script 207 of server 206 causes the Multi- 

25 cast-to Unicast gateway to join the requested-for Multi- 
cast group and adds the requesting client to the list of 
receivers for the requested for Multicast group. For each 
requesting client, server 206 also converts the address 
of the Multicast I P packets of the requested-for group to 

30 the Unicast IP address of the requesting client, and 
sends the Unicast IP packets to the requesting client us- 
ing the well-known User Datagram Protocol (UDP). 
Server 206 also transmits any packets it receives from 
the client to any other Unicast client on that Multicast 

35 group, as well as to the Multicast group address itself 
on the I P Multicast network 101. At step 41 2, when the 
client exits from the multimedia tool, server 206 detects 
that status messages from the client are no longer being 
sent and removes the client from the list of destinations 

40 for the particular Multicast group. 

[0016] The steps associated with a client creating a 
new session are detailed in FIG. 5. At step 501 , as pre- 
viously described in connection with the steps in FIG. 4 
associated with a client joining a session, the SDP lis- 

45 tener process 202 accumulates IP Multicast network 
101 directory announcements into database 204. The 
database is filtered and converted into a standard HTML 
page, where each URL points to information pertaining 
to each Multicast session in the filtered database. At 

50 step 502, the HTTP server 206 listens for requests for 
Multicast sessions/URLs on the HTML page which con- 
tains a list of URLs describing the sessions. When a user 
of a client requests a copy of the page containing the 
Multicast sessions at step 503, the server 206, at step 

55 504, sends a message back to the client requesting a 
login id and password for authentication purposes. If au- 
thentication is successful at step 505, at step 506, server 
206 returns a page to the client containing a list of ses- 
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sions. When the user browses that page and requests 
a specific URL, server 206, at step 507, returns a page 
containing details of the session and buttons enabling 
the client to request a session to start, to create a new 
session, to edit or delete an existing session, and to 
record the current session, the later functionality to be 
described hereinafter. When, at step 508, the user 
"presses" a button to create a new session, at step 509, 
server 206 returns a form to the client requesting the 
client to enter a login id and password appropriate for 
creating a new session, which may or may not be the 
same as the login id and password associated with the 
initial authentication process. If, at step 510, the client 
is authenticated for session creation, server 206 returns 
at step 511 a form to the client with fields to be filled in 
by the user for the session name, session description, 
a URL address for more detailed or related information, 
a field to set the Multicast packet Time to Live value 
(TTL), selection boxes for various media tools, and as- 
sociated coding formats, Multicast addresses and ports 
to use, the name and phone number of a responsible 
person, and the duration of the session announcement. 
When the user fills in the fields and selects a create but- 
ton, the filled-in form is returned to the server 206. Serv- 
er 206 checks that certain key fields are correct and filled 
in. If not, an error message is returned to the client; oth- 
erwise server 206 stores the data in a file that is indexed 
to the login id used to access the form. The data, at step 
512, is then made available to a Session Announcement 
Protocol (SAP) process 210 on MUS 201. At step 513, 
the SAP process 210 periodically announces the ses- 
sion onto a well-known Multicast IP address and port 
reserved for such announcements for a period of time 
equal to the duration field as entered in the form. When 
this time period expires, the SAP process 210 ceases 
to announce the session. 

[0017] A Unicast endpoint can also, in accordance 
with the present invention, request that a session be re- 
corded for later rebroadcast or retrieval on demand. To 
effect such recording, in FIG. 1, a recorder 125 is con- 
nected via LAN 126 to the IP Multicast network 1 01 . The 
flowchart in FIG. 6 details the steps associated with a 
user at a client terminal requesting that a session be 
recorded. As described previously, the client must be 
given a login id and password to enable access to the 
HTTP server 206 which has a list of the I P Multicast ses- 
sions. At step 601 , the SDP listener process 202 accu- 
mulates IP Multicast network 101 directory announce- 
ments into sessions database 204. The database is fil- 
tered and converted into a standard HTML page, where 
each URL points to information pertaining to each Mul- 
ticast session in the filtered database. At step 602, serv- 
er 206 listens for requests for Multicast sessions/URLs 
on the HTML page which contains a list of URLs describ- 
ing the sessions. When, at step 603, a user requests a 
copy of the page containing the Multicast sessions, at 
step 604, server 206 sends a message back to the client 
requesting his or her login id and password for authen- 



tication purposes. If, at step 605, authentication is suc- 
cessful, at step 606, server 206 returns a page to the 
client containing a list of sessions. When a user browses 
that page and requests a URL, server 206, at step 607, 
5 returns a page containing details of the session, and but- 
tons enabling the client to request a session, to start the 
existing session, to create a new session, to edit or de- 
lete an existing session, or to record the current session. 
At step 608, the user "presses" a button to record a ses- 
10 sion and, at step 609, server 206 returns a form to the 
client requesting the user to enter a login id and pass- 
word for recording purposes, which may or may not be 
the same as the login id and password used in a previ- 
ous step. If, at step 610, the client is authenticated for 
15 session recording, server 206 returns a form to the client 
with fields to be filled in or options to be selected. The 
form contains selection boxes for the various media of 
the session, and start and stop date and time fields, as 
well as a start button to "push" when the form is com- 
20 plete. When the user fills in the fields and selects the 
start form, the filled-in form is returned to server 206. 
Server 206 checks that certain key fields are correct and 
filled in. If not, an error message is returned to the client; 
otherwise the server stores the data in a file that is in- 
25 dexed to the login id used to access the form. At step 
61 1 , server 206 sends a message to the recording serv- 
er 125 to start the recording at the specified date and 
time. The recording server 125, at step 612, then 
records the session at the appropriate time using a well- 
30 known program for reading IP Multicast packets in the 
RTP format. At step 61 3, the stored session is retrieved 
on-demand by the user. 

[0018] To support dial-up Unicast endpoint users, pri- 
or art transcoding and rate adapting gateways, such as 
35 transcoder/adapter 127 in FIG. 1, are deployed within 
IP Multicast network 1 01 . As shown in FIG. 1 , transcod- 
er/rate adapter gateway 127 is connected via LAN 128 
to the IP Multicast network 101. Alternatively, transcod- 
er/rate adapter gateway 1 27 may be co-resident with ei- 
40 ther MUS 1 20 or 121. The gateway maps existing high 
bandwidth sessions into low bandwidth versions of the 
same session suitable for 28.8 kbps modems or ISDN 
adapters by using frame discarding algorithms. An- 
nouncements about these rate-controlled sessions are 
45 then placed in the database of IP Multicast network 1 01 
sessions. 

[0019] An alternative mechanism for invoking the 
transcoding/rate adapting gateways could be based on 
user/client action. The steps associated with a client re- 
50 questing that a session be automatically transcoded/ 
rate adapted are detailed in FIGS. 7A and 7B. As de- 
scribed previously, the user of the client must be given 
a login id and a password to enable access to HTTP 
server 206. As described previously, at step 701, the 
55 SDP listener process 202 accumulates IP Multicast net- 
work 101 directory announcements into database 204. 
The database is filtered and converted into a standard 
HTML page, where each URL points to information per- 
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taining to each Multicast session the filtered database. 
It is assumed that a required bandwidth parameter and 
maximum packet loss parameter are associated with 
each session. For sessions using a form as previously 
described, this is accomplished by the use of additional 
fields corresponding to these parameters in the "new 
session" form described hereinabove. At step 702, HT- 
TP server 206 listens for requests for Multicast ses- 
sions/URLs on the HTML page containing a list of URLS 
describing the sessions. When, at step 703, a request 
is received from aclient for acopy of the page containing 
the Multicast sessions, at step 704, server 206 sends a 
message back to the client requesting a login id and 
password for authentication purposes. If, at step 705, 
authentication is successful, at step 706, server 206 re- 
turns a page to the client containing a list of sessions. 
When after the user browses the page, and at step 707, 
selects a session and group(s) within a session, server 
206, at step 708, returns a page containing details of the 
session and buttons enabling the client to request a ses- 
sion to start, to create a new session, to edit or delete 
an existing session, or to record the current session. At 
step 709, the user pushes a button to request the ses- 
sion or specif ic media in the session to start. In response 
thereto, at step 71 0, server 206 launches a control script 
which sends a series of test packets to the client. At step 
71 1 , the client echoes these same packets back to the 
server 206. At step 712, the server computes an esti- 
mate of the available bandwidth and packet loss along 
the path between the server and the client by comparing 
the transmitted test packets with the received test pack- 
ets. If, at decision step 713, the performance require- 
ments of the session exceed that of the path, at step 
714, rate-adaptation or transcoding is needed. If not, the 
process continues as previously described for a client 
joining an existing session. If rate adaptation or trans- 
coding is needed, at step 71 5, one out of plurality of low- 
er rate encodings is selected based on the measured 
characteristics of the path. It is to be assumed that a 
finite set of rate adapted sessions are allowed by the 
server 206. As an example, if the original session was 
128 kbps, rate adaptation to 56 kbps, 28.8 kbps and 20 
kbps may be allowed. At step 716, HTTP server 206 
sends a message to the transcoding/rate adapting gate- 
way 127 indicating which Multicast group is to be joined, 
to what bandwidth the media-type should be rate-adapt- 
ed, what (if any) alternative coding needs to applied, and 
what new Multicast address and port number the trans- 
coded session should use. At step 71 7, a determination 
is made whether that group has already been rate- 
adapted/transcoded. If yes, at step 718, the Multicast 
address and port number corresponding to the already 
rate-adapted/transcoded group is used and the process 
proceeds to step 71 9. If no, at step 720, the transcoder/ 
rate adapter gateway 127 is invoked to transcode the 
session with appropriate bandwidth parameters and to 
re-Multicast the resulting lower-bandwidth session us- 
ing a different Multicast address and port number. At 



step 71 9, the server 206 sends a message to the client 
containing information about which multimedia tool to 
launch, and what UDP sockets (the Unicast IP address 
on the MUS and associated ports) to listen to and to 
5 send information to corresponding to the requested ses- 
sion. At step 721, the control-script causes the MUS 
gateway to join the requested Multicast group and add 
the requesting client to the list of receivers for requested 
Multicast group. For each requesting client, the server 
10 converts the address of the Multicast IP packets of the 
requested-for group to the Unicast IP address of the re- 
questing client, and sends the Unicast IP packets to the 
requesting client using the well-known User Datagram 
Protocol. The server also transmits any packets it re- 
15 ceives from the client to the list of receivers for that Mul- 
ticast group, as well as to the Multicast group address 
itself. At step 722, when the client exits the multimedia 
tool, the HTTP server 206 detects that status messages 
from the client are no longer being sent and removes 
the client from the list of destinations for the particular 
Multicast group. 

[0020] The system described hereinabove is highly 
scaleable in that the MUS and other servers may be dis- 
tributed throughout the Multicast-enabled portion of the 
network. If the number of such endpoints is likely to be 
large, for efficiency, it is preferred that the servers be 
located close to the Unicast client endpoints. For small 
conferencing group, the location or distribution of the 
MUS's is not important. Advantageously, the present in- 
vention enables any IP Multicast-based service to be 
gradually introduced and rolled out on a small scale be- 
fore all clients are enabled for IP Multicast. As clients 
become I P Multicast enabled, there could be a transition 
to a hybrid IP Multicast mode of operation where some 
clients are IP Multicast connected and others are not. 
[0021] Although described in connection with Unicast 
IP endpoints connecting to an IP Multicast network 1 01 
such as the MBONE, the present invention could be em- 
ployed with any IP Multicast network. Further the 
present invention could be employed with any Multicast 
network and Unicast network that operate in a similar 
fashion to IP Multicast and Unicast networks. 
[0022] The above-described embodiments are illus- 
trative of the principles of the present invention. Other 
embodiments could be devised by those skilled in the 
art without departing from the scope of the present in- 
vention. 

[0023] Where technical features mentioned in any 
claim are followed by reference signs, those reference 
signs have been included for the sole purpose of in- 
creasing the intelligibility of the claims and accordingly, 
such reference signs do not have any limiting effect on 
the scope of each element identified by way of example 
by such reference signs. 
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Claims 



A method of providing access to a Multicast session 
and of creating a Multicast session on a Multicast 
network (101) to a Unicast client (110, 111, 115) on 
a Unicast network (107, 108) comprising: 

accumulating at a gateway server (120, 121) in- 
terconnecting the Multicast network (101) and 
the Unicast network (107, 108) directory infor- 
mation relating to Multicast sessions on the 
Multicast network (101); 
supplying the Unicast client (110, 111, 115) with 
the directory information accumulated by the 
gateway server (120, 121); 
receiving at the gateway server (1 20, 1 21 ) from 
the Unicast client (110, 111, 115) a request to 
join or to create a Multicast session; 
responding to the request by 

(i) joining the requested-for Multicast ses- 
sion at the gateway server (120, 121) on 
behalf of the Unicast client (110,111,115) 
when the request is to join a Multicast ses- 
sion chosen from the directory information; 
or 

(ii) receiving and storing at the gateway 
server (120, 121) information about the 
Multicast session and announcing the Mul- 
ticast session by the gateway server (120, 
121) onto the Multicast network (101) to a 
predetermined Multicast address for such 
announcements when the request is to cre- 
ate a new Multicast session; 

the method further comprising 
converting at the gateway server (1 20, 1 21 ) an 
address of Multicast packets received on a Mul- 
ticast address associated with the requested- 
for session to a Unicast address of the Unicast 
client (110,111,115) and sending the Multicast 
packets received by the gateway server (120, 
121) on the Multicast address to the Unicast cli- 
ent (110,111,115); and 

transmitting packets received at the gateway 
server (120, 121) from the Unicast client (110, 
111, 115) to the Multicast address associated 
with the requested-for session. 

The method of claim 1 wherein the request is a re- 
quest to join at least one group of a plurality of 
groups associated with the Multicast session, each 
of said plurality of groups having an associated Mul- 
ticast address. 

The method of claim 2 wherein each of said at least 
one group is associated with a different media type. 



15 



20 



The method of claim 1 further comprising before 
supplying the Unicast client (110, 111, 115) with the 
directory information, authenticating the Unicast cli- 
ent (110, 111, 115). 

The method of claim 4 wherein the authenticating 
comprises receiving at the gateway server (120, 
121) a login identity and a password from the Uni- 
cast client (110, 111, 115). 

The method of claim 1 wherein the Unicast and Mul- 
ticast networks (107, 108, 101) are IP (Internet Pro- 
tocol) Unicast and IP Multicast networks, respec- 
tively. 

The method of claim 6 wherein packets are trans- 
mitted between the gateway server (1 20, 121) and 
the Unicast client (110,111,115) using the User Da- 
tagram Protocol. 

The method of claim 6 wherein the directory infor- 
mation comprises an HTML page having a plurality 
of URLs each pointing to information associated 
with a Multicast session on the IP Multicast network 
(101). 

The method of claim 6 wherein the IP Multicast net- 
work (101) is the MBONE. 



30 10. The method of claim 1 wherein the session is an- 
nounced periodically onto the Multicast network 
(101). 

11. The method of claim 1 further comprising after re- 
35 ceiving a request at the gateway server (1 20, 121) 
from the Unicast client (110, 111, 115) to create a 
session, authenticating the Unicast client (110,111, 
115) to create a session. 

40 12. The method of claim 1 further comprising 

receiving a request at the gateway server 
(1 20, 1 21 ) from the Unicast client (1 1 0, 1 1 1 , 1 1 5) to 
record a selected Multicast session chosen from the 
directory information; and 

45 sending a message containing information 

about the selected Multicast session from the gate- 
way server (120, 121) to a recording server (125) 
connected to the Multicast network (101) to record 
the selected session. 



25 



50 



55 



13. The method of claim 12 wherein the Unicast net- 
work (1 07, 1 08) and the Multicast network (1 01 ) are 
IP (Internet Protocol) Unicast and IP Multicast net- 
works, respectively. 

14. The method of claim 12furthercomprising receiving 
at the gateway server (120, 121) from the Unicast 
client (110,111,115) information about the selected 
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Multicast session, including information relating to 
when to start and stop recording. 

15. The method of claim 14 wherein the information re- 
ceived at the gateway server (120, 121) from the 
Unicast client (110, 111, 115) further includes an 
identification of specific media for recording of the 
selected Multicast session. 

16. The method of claim 12 further comprising after re- 
ceiving a request at the gateway server (120, 121) 
from the Unicast client (110, 111 , 115) to record a 
session, authenticating the Unicast client 
(110,111 ,115) to record a session. 

17. The method of claim 12 further comprising: 

receiving a request at the gateway server (1 20, 

121) from the Unicast client (110, 111, 115) to 

access the recorded session; 

sending a message to the recording server 

(1 25) from the gateway server (1 20, 1 21 ) to the 

recording server (125) to retrieve the recorded 

session; 

receiving the recorded session at the gateway 
server (120, 121); and 

sending the recorded session from the gateway 
server (1 20, 1 21 ) to the Unicast client (110,111, 
115). 

18. The method of claim 1 further comprising 

determining an estimate of the available 
bandwidth between the gateway server (120, 121) 
and the Unicast client (110, 111, 115); 

selecting a coding rate lower than a coding 
rate associated with the selected session when the 
estimate of the available bandwidth is less than the 
required bandwidth for the selected session; 

sending a message from the gateway server 
(1 20, 1 21 ) to a transcoding server (1 27) connected 
to the Multicast network (1 01 ) to rate-adapt the cod- 
ing rate associated with the selected session to the 
selected lower coding rate; 

receiving at the gateway server (120, 121) 
from the transcoding server (127) an indication of 
the Multicast address to which the rate-adapted se- 
lected session is being transmitted; and 

wherein 

said joining requested-for Multicast session 
comprises joining the rate-adapted session on be- 
half of the Unicast client (1 1 0, 1 1 1 , 1 1 5) at the gate- 
way server (1 20, 1 21 ) on the indicated Multicast ad- 
dress to which the rate-adapted selected session is 
being transmitted; and 

said converting comprises converting the ad- 
dress of the Multicast packets received on the Mul- 
ticast address to which the rate-adapted selected 
session is being transmitted to said Unicast address 



of the Unicast client (110, 111, 115) and sending the 
Multicast packets received by the gateway server 
(1 20, 1 21 ) on that Multicast address to the Unicast 
client (110, 111, 115). 

5 

19. The method of claim 18 wherein the Unicast and 
Multicast networks (107, 108, 101) are IP (Internet 
Protocol) Unicast networks and IP Multicast net- 
works, respectively. 

10 

20. The method of claim 1 8 wherein the request to join 
a Multicast session is a request to join at least one 
group of a plurality of groups associated with the 
Multicast session, each of said plurality of groups 

15 having an associated Multicast address. 

21. The method of claim 20 wherein each of said plu- 
rality of groups is associated with a different media 
type. 

20 

22. The method of claim 18 wherein said determining 
an estimate of the available bandwidth comprises: 

transmitting a series of test packets to the Uni- 
25 cast client (110, 111, 115); 

receiving an echo of these test packets back 
from the Unicast client (110, 111 , 115); and 
comparing the transmitted series of test-pack- 
ets with the received echo of these test packets. 

30 

23. A Multicast-Unicast server (120, 121 ) comprising: 

means (202, 204) for accumulating from a con- 
nected-to Multicast network (101) directory in- 
35 formation relating to Multicast sessions on the 

Multicast network (101); 
means (206) for receiving from a Unicast client 
(110, 111, 11 5) on a Unicast network (107, 108) 
connected to the server (1 20, 1 21 ) a request to 
40 join a Multicast session from among the ses- 

sions accumulated in the directory information; 
means (207) for joining the requested-for Mul- 
ticast session on behalf of the client (110, 111, 
115); and 

45 means for (208) converting the Multicast ad- 

dress of the Multicast packets on the request- 
ed-for Multicast session to a Unicast address 
associated with the Unicast client (110, 111, 
115) and for sending the Multicast packets on 
50 the requested-for Multicast session to the Uni- 

cast client (110, 111, 115) at that Unicast ad- 
dress, and for sending packets received from 
the Unicast client (110, 111, 115) to the Multi- 
cast address associated with the selected ses- 
55 sion. 

24. The server (1 20, 1 21 ) of claim 23 wherein the Mul- 
ticast network (101) and the Unicast network (107, 
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108) the server (120, 121) is connected to are an 
IP (Internet Protocol) Multicast network and an IP 
Unicast network, respectively. 

25. The server (120, 121) of claim 24 wherein packets 
are transmitted between the server (120, 121) and 
the Unicast client (110, 111, 115) using the User Da- 
tagram Protocol. 

26. The server (120, 121) of claim 23 wherein the re- 
quest to join a Multicast session is a request to join 
at least one group of a plurality of groups associated 
with the Multicast session, each of plurality of 
groups having an associated Multicast address. 

27. The server (120, 121) of claim 26 wherein each of 
said plurality of groups is associated with a different 
media type. 

28. The server (120, 121) of claim 23 wherein the 
means (208) for converting also sends packets re- 
ceived from the Unicast client (110, 111, 1 1 5) to an- 
other Unicast client (110, 111, 115) associated with 
the server (1 20, 1 21 ) and which said another client 
(1 1 0, 1 1 1 , 1 1 5) is also connected to the session. 



Patentanspriiche 

1 . Ein Verfahren, das einem Unicast-Client (110, 111, 
115) in einem Unicast-Netzwerk (107, 108) einen 
Zugriff auf eine Multicast-Sitzung und ein Erzeugen 
einer Multicast-Sitzung in einem Multicast-Netz- 
werk (101) bereitstellt, das folgendes umfasst: 

das Akkumulieren an einem Gateway-Server 
(120, 121), der das Multicast-Netzwerk (101) 
und das Unicast-Netzwerk (1 07, 1 08) miteinan- 
der verbindet, von Verzeichnisinformation, die 
die Multicast-Sitzungen in dem Multicast-Netz- 
werk (101) betrifft; 

das Versorgen des Unicast-Clients (110, 111, 
115) mit der Verzeichnisinformation, die vom 
Gateway-Server (120, 121) akkumuliert wird; 
das Empfangen am Gateway-Server (120, 
121) vom Unicast-Client (110, 111, 115) einer 
Anfragezum Beitreten an eineoderzum Erzeu- 
gen einer Multicast-Sitzung; 
das Reagieren auf die Anfrage, indem 

(i) der angefragten Multicast-Sitzung am 
Gateway-Server (120, 121) namens des 
Unicast-Clients (1 1 0, 1 1 1 , 1 1 5) beigetreten 
wird, wenn die Anfrage lautet, einer von der 
Verzeichnisinformation ausgewahlten Mul- 
ticast-Sitzung beizutreten; oder 

(ii) indem am Gateway-Server (120, 121) 
die Information liber die Multicast-Sitzung 



empfangen und gespeichert wird und die 
Multicast-Sitzung durch den Gateway-Ser- 
ver (120, 121) in das Multicast-Netzwerk 
(101) auf eine vorbestimmte Multicast- 
5 Adresse fur solche Ansagen angesagt 

wird, wenn die Anfrage lautet, eine neue 
Multicast-Sitzung zu erzeugen; 

wobei das Verfahren weiterhin folgendes um- 

10 fasst: 

das Konvertieren am Gateway-Server (120, 
121) einer Adresse von Multicast-Paketen, die 
an einer Multicast-Adresse empfangen wer- 
15 den, die mit der angefragten Sitzung verknijpft 

ist, in eine Unicast-Adresse des Unicast-Cli- 
ents (110, 111, 115) und das Senden der Mul- 
ticast- Pakete, die durch den Gateway-Server 
(120, 121) an der Multicast-Adresse empfange- 
20 nen werden, an den Unicast-Client (110, 111, 

115); und 

das Senden der Pakete, die am Gateway-Ser- 
ver (120, 121) vom Unicast-Client (110, 111, 
115) empfangenen werden, an die Multicast- 
25 Adresse, die mit der angefragten Sitzung ver- 

knijpft ist. 

2. Das Verfahren nach Anspruch 1 , worin die Anfrage 
eine Anfrage zum Beitreten von mindestens einer 
30 Gruppe einer Mehrzahl von Gruppen ist, die mit der 
Multicast-Sitzung verknijpft ist, wobei jede der 
Mehrzahl von Gruppen eine verknupfte Multicast- 
Adresse hat. 

35 3. Das Verfahren nach Anspruch 2, worin jede der 
mindestens einen Gruppe mit einer unterschiedli- 
chen Medienart verknijpft ist. 

4. Das Verfahren nach Anspruch 1 , das weiterhin vor 
40 der Versorgung des Unicast-Clients (110, 111, 115) 

mit der Verzeichnisinformation die Authentifizie- 
rung des Unicast-Clients (110, 111, 115) umfasst. 

5. Das Verfahren nach Anspruch 4, worin die Authen- 
45 tifizierung das Empfangen am Gateway-Server 

(120, 121) einer Anmelde-ldentitat und eines Kenn- 
worts vom Unicast-Client (110, 111, 115) umfasst. 

6. Das Verfahren nach Anspruch 1 , worin die Unicast- 
50 und Multicast-Netzwerke (1 07, 1 08, 1 01 ) jeweils IP 

(Internetprotokoll)-Unicast- und IP-Multicast-Netz- 
werke sind. 

7. Das Verfahren nach Anspruch 6, worin die Pakete 
55 zwischen dem Gateway-Server (1 20, 1 21 ) und dem 

Unicast-Client (110, 111, 115) mittels Verwendung 
des Benutzer-Datagramm-Protokolls gesendet 
werden. 
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8. Das Verfahren nach Anspruch 6, worin die Ver- 
zeichnisinformation eine HTML-Seite umfasst, die 
eine Mehrzahl von URLs hat, wobei jede auf Infor- 
mation zeigt, die mit einer Multicast-Sitzung in dem 
IP-Multicast-Netzwerk (101) verknupft ist. 5 

9. Das Verfahren nach Anspruch 6, worin das IP-Mul- 
ticast-Netzwerk (101) MBONE ist. 

10. Das Verfahren nach Anspruch 1 , worin die Sitzung 10 
periodisch in dem Multicast-Netzwerk (101) ange- 
sagt wird. 

1 1 . Das Verfahren nach Anspruch 1 , das weiterhin nach 
dem Empfang einer Anfrage vom Unicast-Client 15 
(1 1 0, 1 1 1 , 1 1 5) am Gateway-Server (1 20, 1 21 ) zum 
Erzeugen einer Sitzung die Authentifizierung des 
Unicast-Clients (110,111,115) fur das Erzeugen ei- 
ner Sitzung umfasst. 

20 

12. Das Verfahren nach Anspruch 1, das weiterhin fol- 
gendes umfasst: 

das Empfangen einer Anfrage am Gateway- 
Server (120, 121) vom Unicast-Client (110, 111, 25 
115) zum Aufzeichnen einer ausgewahlten 
Multicast-Sitzung, die von der Verzeichnisinfor- 
mation ausgewahlt wird; und 
das Senden einer Nachricht, die eine Informa- 
tion uber die ausgewahlte Sitzung vom Gate- 30 
way-Server (120, 121) enthalt, an einen mit 
dem Multicast-Netzwerk (101) verbundenen 
aufzeichnenden Server (125), urn die ausge- 
wahlte Sitzung aufzuzeichnen. 

35 

13. Das Verfahren nach Anspruch 12, worin das Uni- 
cast-Netzwerk (107, 108) und das Multicast-Netz- 
werk (101) jeweils IP-(lnternetprotokoll)-Unicast- 
und IP-Multicast-Netzwerke sind. 

40 

14. Das Verfahren nach Anspruch 12, das weiterhin das 
Empfangen am Gateway-Server (120, 121) vom 
Unicast-Client (110, 111 , 115) von Information uber 
die ausgewahlte Multicast-Sitzung umfasst, die In- 
formation daruber einschlieBt, wann die Aufzeich- 45 
nung gestartet und gestoppt wird. 

15. Das Verfahren nach Anspruch 14, worin die am Ga- 
teway-Server (120, 121) vom Unicast-Client (110, 
111, 115) empfangene Information weiterhin eine 50 
Identifizierung der speziellen Medien fur die Auf- 
zeichnung der ausgewahlten Multicast-Sitzung ein- 
schlieBt. 

16. Das Verfahren nach Anspruch 12, das weiterhin 55 
nach dem Empfang einer Anfrage am Gateway- 
Server (120, 121) vom Unicast-Client (110, 111, 

1 1 5) zur Aufzeichnung einer Sitzung die Authentifi- 



zierung des Unicast-Clients (110, 111, 115) zum 
Aufzeichnen einer Sitzung umfasst. 

17. Das Verfahren nach Anspruch 12, das weiterhin fol- 
gends umfasst: 

das Empfangen einer Anfrage am Gateway- 
Server (1 20, 1 21 ) vom Unicast-Client (1 1 0, 1 1 1 , 
115) zum Zugriff auf die aufgezeichnete Sit- 
zung; 

das Senden einer Nachricht an den aufzeich- 
nenden Server (125) vom Gateway-Server 
(120, 121), damit der aufzeichnende Server 
(125) die aufgezeichnete Sitzung wiederge- 
winnt; 

das Empfangen der aufgezeichneten Sitzung 
am Gateway-Server (120, 121); und 
das Senden der aufgezeichneten Sitzung vom 
Gateway-Server (120, 121) an den Unicast-Cli- 
ent (110, 111, 115). 

18. Das Verfahren nach Anspruch 1 , das weiterhin fol- 
gendes umfasst: 

das Bestimmen eines Schatzwerts der verfug- 
baren Bandbreite zwischen dem Gateway-Ser- 
ver (120, 121) und dem Unicast-Client (110, 
111, 115); 

das Auswahlen einer Codiergeschwindigkeit, 
die geringer ist als eine mit der ausgewahlten 
Sitzung verknupfte Codiergeschwindigkeit, 
wenn der Schatzwert der verfugbaren Band- 
breite kleiner ist als die erforderliche Bandbrei- 
te fur die ausgewahlte Sitzung; 
das Senden einer Nachricht vom Gateway-Ser- 
ver (120, 121) an einen mit dem Multicast-Netz- 
werk (101) verbundenen Codewandler-Server 
(127), urn die mit der ausgewahlten Sitzung 
verknupfte Codiergeschwindigkeit an die aus- 
gewahlte geringere Codiergeschwindigkeit der 
Geschwindigkeit nach anzupassen; 
das Empfangen am Gateway-Server (120, 
1 21 ) vom Codewandler-Server (1 27) einer An- 
zeige der Multicast-Adresse, an die die Ge- 
schwindigkeit-angepaBte ausgewahlte Sitzung 
gesendet wird; und worin 
das Beitreten in die angefragte Multicast-Sit- 
zung das Beitreten in die Geschwindigkeit-an- 
gepaBten Sitzung namens des Unicast-Clients 
(110, 111, 115) am Gateway-Server (120, 121) 
an der angezeigten Multicast-Adresse umfasst, 
an die die Geschwindigkeit-angepaBte ausge- 
wahlte Sitzung gesendet wird; und 
das Konvertieren der Adresse der an der Mul- 
ticast-Adresse empfangenen Multicast- Pake- 
te, an die die Geschwindigkeit-angepaBte aus- 
gewahlte Sitzung gesendet wird, in die Unicast- 
Adresse des Unicast-Clients (110, 111, 115) 
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und das Senden der vom Gateway-Server 
(120, 121) an dieser Multicast- Ad resse emp- 
fangenen Multicast-Pakete an den Unicast-Cli- 
ent(110, 111, 115). 

5 

19. Das Verfahren nach Anspruch 18, worin das Uni- 
cast- und das Multicast-Netzwerk (107, 108, 101) 
jeweils IP-(lnternetprotokoll)-Unicast-Netzwerke 
und IP-Multicast-Netzwerke sind. 

10 

20. Das Verfahren nach Anspruch 1 8, worin die Anfrage 
zum Beitreten in eine Multicast-Sitzung eine Anfra- 
ge zum Beitreten von mindestens einer Gruppe ei- 
ner Mehrzahl von Gruppen ist, die mit der Multicast- 
Sitzung verknupft sind, wobei jede der Mehrzahl 15 
von Gruppen eine verknupfte Multicast-Adresse 
hat. 

21. Das Verfahren nach Anspruch 20, worin jede der 
Mehrzahl von Gruppen mit einer unterschiedlichen 20 
Medienart verknupft ist. 

22. Das Verfahren nach Anspruch 1 8, worin die Bestim- 
mung eines Schatzwerts der verfugbaren Bandbrei- 

te folgendes umfasst: 25 



23. Ein Multicast-Unicast-Server(120, 121), derfolgen- 35 
des umfasst: 



Unicast-Client (110, 111 , 115) an jener Unicast- 
Adresse und zum Senden von Paketen, die 
vom Unicast-Client (110, 111, 115) empfangen 
werden, an die mit der ausgewahlten Sitzung 
verknupfte Multicast-Adresse. 

24. Der Server (1 20, 121 ) nach Anspruch 23, worin das 
Multicast-Netzwerk (101) und das Unicast-Netz- 
werk (1 07, 1 08), an das der Server (1 20, 121) ver- 
bunden ist, jeweils ein IP-(lnternetprotokoll)-Multi- 
cast-Netzwerk und ein IP-Unicast-Netzwerk ist. 

25. Der Server (120, 121) nach Anspruch 24, worin die 
Pakete mittels Verwendung des Benutzer-Data- 
gramm-Protokolls zwischen dem Server (1 20, 121) 
und dem Unicast-Client (110, 111, 115) gesendet 
werden. 

26. Der Server (120, 121) nach Anspruch 23, worin die 
Anfrage zum Beitreten einer Multicast-Sitzung eine 
Anfrage zum Beitreten von mindestens einer Grup- 
pe aus einer Mehrzahl von Gruppen ist, die mit der 
Multicast-Sitzung verknupft sind, wobei jede der 
Mehrzahl von Gruppen eine verknupfte Multicast- 
Adresse hat. 

27. Der Server (1 20, 1 21 ) nach Anspruch 26, worin jede 
der Mehrzahl von Gruppen mit einer unterschiedli- 
chen Medienart verknupft ist. 

28. Der Server (1 20, 1 21 ) nach Anspruch 23, worin das 
Mittel (208) zum Konvertieren auch die vom Uni- 
cast-Client (110,111,115) empfangenen Pakete an 
einen anderen mit dem Server (1 20, 1 21 ) verknupf- 
ten Unicast-Client (110, 111, 115) sendet, wobei der 
andere Client (110, 111, 115) ebenfalls mit der Sit- 
zung verknupft ist. 



Revendications 

1. Procede pour fournir un acces a une session de 
multidiffusion et creer une session de multidiffusion 
sur un reseau a multidiffusion (101) vers un client 
de diffusion individuelle (110, 111, 115) sur un re- 
seau a diffusion individuelle (107, 108), comportant 
les etapes consistant a : 

accumulerdans un serveurde passerelle (120, 
121) interconnectant le reseau a multidiffusion 
(1 01 ) et le reseau a diffusion individuelle (1 07, 
1 08) des informations de repertoire se rappor- 
tant a des sessions de multidiffusion sur le re- 
seau a multidiffusion (101), 
delivrer au client de diffusion individuelle (110, 
111, 115) les informations de repertoire accu- 
mulees par le serveur de passerelle (1 20, 121), 
recevoir dans le serveur de passerelle (120, 



ein Mittel (202, 204), urn von einem damit ver- 
bundenen Multicast-Netzwerk (101) Verzeich- 
nisinformation zu akkumulieren, die Multicast- 40 
Sitzungen in dem Multicast-Netzwerk (1 01 ) be- 
trifft; 

ein Mittel (206), urn von einem Unicast-Client 
(110, 111, 115) in einem mit dem Server (120, 
121) verbundenen Unicast-Netzwerk (107, 45 
108) eine Anfrage zum Beitreten einer Multi- 
cast-Sitzung unter den in der Verzeichnisinfor- 
mation akkumulierten Sitzungen zu empfan- 
gen; 

ein Mittel (207) zum Beitreten der angefragten 50 
Multicast-Sitzung namens des Clients (110, 
111, 115); und 

ein Mittel (208) zum Konvertieren der Multicast- 
Adresse der Multicast-Pakete an der angefrag- 
ten Multicast-Sitzung in eine mit dem Uni- 55 
cast-Client (110, 111, 115) verknupfte Unicast- 
Adresse, und zum Senden der Multicast-Pake- 
te an der angefragten Multicast-Sitzung an den 



das Senden einer Reihe an Testpaketen an den 
Unicast-Client (110, 111, 115); 
das Empfangen eines Echos dieser Testpakete 
zuruckvom Unicast-Client (110, 111,115); und 30 
das Vergleichen der gesendeten Reihe an Test- 
paketen mit dem empfangenen Echo dieser 
Testpakete. 



11 



21 



EP 0 902 569 B1 



22 



121) a partir du client de diffusion individuelle 
(110, 111, 115) une demande de liaison a une 
session de multidiffusion ou de creation d'une 
session de multidiffusion, 
repondre a la demande 

(i) en assurant la liaison a la session de 
multidiffusion demandee dans le serveur 
de passerelle (120, 121) au nom du client 
de diffusion individuelle (110, 111, 115) 
lorsque la demande consiste a assurer la 
liaison a une session de multidiffusion se- 
lectionnee d'apres les informations de re- 
pertoire, ou 

(ii) en recevant et en memorisant dans le 
serveur de passerelle (1 20, 1 21 ) des infor- 
mations concernant la session de multidif- 
fusion et en annoncant la session de mul- 
tidiffusion par le serveur de passerelle 
(120, 121) sur le reseau a multidiffusion 
(101) a une adresse de multidiffusion pre- 
determine pour de telles annonces lors- 
que la demande consiste a creer une nou- 
velle session de multidiffusion, 

le procede comportant en outre les etapes con- 
sistant a : 

convertir dans le serveur de passerelle 
(1 20, 1 21 ) une adresse de paquets de mul- 
tidiffusion recus sur une adresse de multi- 
diffusion associee a la session demandee 
en une adresse de diffusion individuelle du 
client de diffusion individuelle (110, 111, 
115) et envoyer les paquets de multidiffu- 
sion recus par le serveur de passerelle 
(120, 121) sur I'adresse de multidiffusion 
au client de diffusion individuelle (110, 111, 
115), et 

transmettre les paquets recus dans le ser- 
veur de passerelle (120, 121) a partir du 
client de diffusion individuelle (110, 111, 
115) a I'adresse de multidiffusion associee 
a la session demandee. 

2. Procede selon la revendication 1 , dans lequel la de- 
mande est une demande de liaison a au moins un 
groupe d'une pluralite de groupes associes a lases- 
sion de multidiffusion, chacun de ladite pluralite de 
groupes ayant une adresse de multidiffusion asso- 
ciee. 

3. Procede selon la revendication 2, dans lequel cha- 
cun dudit au moins un groupe est associe a un type 
de support different. 

4. Procede selon la revendication 1, comportant en 
outre, avant de delivrer au client de diffusion indivi- 



duelle (1 1 0, 1 1 1 , 1 1 5) les informations de repertoire, 
I'authentification du client de diffusion individuelle 
(110, 111, 115). 

5 5. Procede selon la revendication 4, dans lequel 
I'authentification comporte la reception dans le ser- 
veur de passerelle (120, 121) d'une identite 
d'ouverture de session et d'un mot de passe prove- 
nant du client de diffusion individuelle (110, 111, 

10 115). 

6. Procede selon la revendication 1 , dans lequel les 
reseaux a diffusion individuelle et a multidiffusion 
(1 07, 1 08, 1 01 ) sont des reseaux a diffusion indivi- 

15 duelle a Protocole Internet (IP) et a multidiffusion 
IP, respectivement. 

7. Procede selon la revendication 6, dans lequel les 
paquets sont transmis entre le serveur de passerel- 

20 le (120, 121) et le client de diffusion individuelle 
(110, 111 , 115) en utilisant le Protocole Datagram- 
me Utilisateur. 

8. Procede selon la revendication 6, dans lequel les 
25 informations de repertoire comportent une page de 

description de documents hypertextuels (HTML) 
ayant une pluralite d'adresses uniformisees de res- 
sources (URL) chacune pointant vers des informa- 
tions associees a une session de multidiffusion sur 
30 le reseau a multidiffusion IP (101). 

9. Procede selon la revendication 6, dans lequel le re- 
seau a multidiffusion I P (1 01 ) est le reseau MBON E. 

35 10. Procede selon la revendication 1, dans lequel la 
session estannonceeperiodiquementsurle reseau 
a multidiffusion (101). 

11. Procede selon la revendication 1, comportant en 
40 outre, apres la reception d'une demande dans le 

serveur de passerelle (1 20, 121) en provenance du 
client de diffusion individuelle (110, 111, 115) pour 
creer une session, I'authentification du client de dif- 
fusion individuelle (110, 111, 115) pour creer une 
45 session. 

12. Procede selon la revendication 1, comportant en 
outre les etapes consistant a : 

50 recevoir une demande dans le serveur de pas- 

serelle (120, 121) depuis le client de diffusion 
individuelle (110, 111, 115) pour enregistrer une 
session de multidiffusion selectionnee choisie 
parmi les informations de repertoire, et 
55 envoyer un message contenant des informa- 

tions concernant la session de multidiffusion 
selectionnee a partir du serveur de passerelle 
(1 20, 1 21 ) a un serveur d'enregistrement (1 25) 
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connecte au reseau a multidiffusion (1 01 ) pour 
enregistrer la session selectionnee. 

13. Procede selon la revendication 12, dans lequel le 
reseau a diffusion individuelle (107, 108) et le re- 
seau a multidiffusion (101) sont des reseaux a dif- 
fusion individuelle a Protocole Internet (IP) et a mul- 
tidiffusion IP, respectivement. 

14. Procede selon la revendication 12, comportant en 
outre la reception dans le serveur de passerelle 
(120, 121) en provenance du client de diffusion in- 
dividuelle (110, 111, 115) d'informations concernant 
la session de multidiffusion selectionnee, y compris 
des informations concernant les instants de debut 
et de fin de I'enregistrement. 

15. Procede selon la revendication 14, dans lequel les 
informations recues dans le serveur de passerelle 
(1 20, 1 21 ) depuis le client de diffusion individuelle 
(110, 111, 115) incluent en outre une identification 
de supports specifiques pour I'enregistrement de la 
session de multidiffusion selectionnee. 

16. Procede selon la revendication 12, comportant en 
outre, apres reception d'une demande dans le ser- 
veur de passerelle (1 20, 121 ) depuis le client de dif- 
fusion individuelle (110, 111, 115) pour enregistrer 
une session, I'authentification du client de diffusion 
individuelle (110, 111, 115) pour enregistrer une 
session. 

17. Procede selon la revendication 12, comportant en 
outre les etapes consistant a : 

recevoir une demande dans le serveur de pas- 
serelle (120, 121) depuis le client de diffusion 
individuelle (110, 111, 115) pour acceder a la 
session enregistree, 

envoyer un message au serveur d'enregistre- 
ment (125) a partir du serveur de passerelle 
(120, 121) au serveur d'enregistrement (125) 
pour rechercher la session enregistree, 
recevoir la session enregistree dans le serveur 
de passerelle (120, 121), et 
envoyer la session enregistree a partir du ser- 
veur de passerelle (120, 121) au client de dif- 
fusion individuelle (110, 111, 115). 

18. Procede selon la revendication 1, comportant en 
outre les etapes consistant a : 

determiner une estimation de la largeur de ban- 
de disponible entre le serveur de passerelle 
(120, 121) et le client de diffusion individuelle 
(110, 111, 115), 

selectionner une Vitesse de codage inferieure 
a une Vitesse de codage associee a la session 



selectionnee lorsque I'estimation de la largeur 
de bande disponible est inferieure a la largeur 
de bande requise pour la session selectionnee, 
envoyer un message depuis le serveur de pas- 

5 serelle (1 20, 1 21 ) a un serveur de transcodage 

(1 27) connecte au reseau a multidiffusion (101) 
pour une adaptation de Vitesse de la Vitesse de 
codage associee a la session selectionnee a la 
Vitesse de codage inferieure selectionnee, 

10 recevoir dans le serveur de passerelle (120, 

121) a partir du serveur de transcodage (127) 
une indication de I'adresse de multidiffusion a 
laquelle la session selectionnee a Vitesse 
adaptee est transmise, et 

15 

dans lequel 

ladite liaison a la session de multidiffusion de- 
mandee comporte la liaison a la session a Vitesse 
adaptee au nom du client de diffusion individuelle 
20 (110,111,115) dans le serveur de passerelle (1 20, 
121) sur I'adresse de multidiffusion indiquee a la- 
quelle la session selectionnee a vitesse adaptee est 
transmise, et 

ladite conversion comporte la conversion de 
25 I'adresse des paquets de multidiffusion regus sur 
I'adresse de multidiffusion a laquelle la session se- 
lectionnee a vitesse adaptee est transmise en ladite 
adresse de diffusion individuelle du client de diffu- 
sion individuelle (110, 111, 115) et I'envoi des pa- 
30 quets de multidiffusion recus par le serveur de pas- 
serelle (120, 121) sur cette adresse de multidiffu- 
sion au client de diffusion individuelle (110, 111, 
115). 

35 19. Procede selon la revendication 1 8, dans lequel les 
reseaux a diffusion individuelle et a multidiffusion 
(1 07, 1 08, 1 01 ) sont des reseaux a diffusion indivi- 
duelle a Protocole Internet (IP) et des reseaux a 
multidiffusion IP, respectivement. 

40 

20. Procede selon la revendication 18, dans lequel la 
demande de liaison a une session de multidiffusion 
est une demande pour etre relie a au moins un grou- 
pe d'une pluralite de groupes associes a la session 

45 de multidiffusion, chacun de ladite pluralite de grou- 
pes ayant une adresse de multidiffusion associee. 

21 . Procede selon la revendication 20, dans lequel cha- 
cun de ladite pluralite de groupes est associe a un 

50 type de support different. 

22. Procede selon la revendication 18, dans lequel la- 
dite determination d'une estimation de la largeur de 
bande disponible comporte les etapes consistant 

55 a : 

transmettre une serie de paquets de test au 
client de diffusion individuelle (110, 111, 115), 
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recevoir un echo de ces paquets de test en re- 
tour a partir du client de diffusion individuelle 
(110, 111, 115), et 

comparer la serie transmise de paquets de test 
a I'echo regu de ces paquets de test. 

23. Serveur de multidiffusion-diffusion individuelle 
(120, 121), comportant : 



27. Serveur (120, 121) selon la revendication 26, dans 
lequel chacun de ladite pluralite de groupes est as- 
socie a un type de support different. 

5 28. Serveur (120, 121) selon la revendication 23, dans 
lequel les moyens de conversion (208) envoient 
egalement des paquets recus depuis le client de dif- 
fusion individuelle (110, 111, 115) a un autre client 
de diffusion individuelle (110, 111, 115) associe au 
serveur (120, 121) et ledit autre client (110, 111, 
115) est egalement connecte a la session. 



des moyens (202, 204) pour accumuler a partir 10 
d'un reseau a multidiffusion connecte a ceux-ci 
(101) des informations de repertoire concer- 
nant des sessions de multidiffusion sur le re- 
seau a multidiffusion (101), 

des moyens (206) pour recevoir a partir d'un 15 
client de diffusion individuelle (110, 111, 115) 
sur un reseau a diffusion individuelle (1 07, 1 08) 
connecte au serveur (120, 121) une demande 
de liaison a une session de multidiffusion parmi 
les sessions accumulees dans les informations 20 
de repertoire, 

des moyens (207) pour effectuer la liaison a la 
session de multidiffusion demandee au nom du 
client (110, 111, 115), et 

des moyens (208) pour convertir I'adresse de 25 
multidiffusion des paquets de multidiffusion sur 
la session de multidiffusion demandee en une 
adresse de diffusion individuelle associee au 
client de diffusion individuelle (1 1 0, 1 1 1 , 1 1 5) et 
pour envoyer les paquets de multidiffusion sur 30 
lasession de multidiffusion demandee au client 
de diffusion individuelle (110, 111, 1 1 5) a cette 
adresse de diffusion individuelle, et pour en- 
voyer les paquets recus depuis le client de dif- 
fusion individuelle (110, 111, 115) a I'adresse 35 
de multidiffusion associee a la session selec- 
tionnee. 



24. Serveur (120, 121) selon la revendication 23, dans 
lequel le reseau a multidiffusion (101) et le reseau 40 
a diffusion individuelle (107, 108) auxquels le ser- 
veur (1 20, 121 ) est connecte sont un reseau a mul- 
tidiffusion a Protocole Internet (IP) et un reseau a 
diffusion individuelle IP, respectivement. 

45 

25. Serveur (120, 121) selon la revendication 24, dans 
lequel des paquets sont transmis entre le serveur 
(120, 121) et le client de diffusion individuelle (110, 
111, 1 1 5) en utilisant le Protocole Datagramme Uti- 
lisateur. 50 



26. Serveur (120, 121) selon la revendication 23, dans 
lequel la demande de liaison a une session de mul- 
tidiffusion est une demande pour etre relie a au 
moins un groupe d'une pluralite de groupes asso- 55 
cies a la session de multidiffusion, chacun de la plu- 
ralite de groupes ayant une adresse de multidiffu- 
sion associee. 
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FIG. 7A 
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